Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor updates to JDBC caching client #8652

Merged
merged 3 commits into from
Aug 9, 2021

Conversation

posulliv
Copy link
Contributor

Some minor updates to the JDBC caching client that are useful for cluster admins:

  • add a default size limit of 10,000 for the cache
  • add a new config option to specify a size for the number of objects to cache
  • expose cache statistics through JMX
  • add a MBean method flushCache to allow invalidating of the cache

Copy link
Member

@findepi findepi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please rebase

@@ -45,7 +45,7 @@ public JdbcMetadata create(JdbcTransactionHandle transaction)
jdbcClient,
Set.of(),
new SingletonJdbcIdentityCacheMapping(),
new Duration(1, DAYS), true),
new Duration(1, DAYS), true, 10000),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Integer.MAX_VALUE here.

Copy link
Member

@hashhar hashhar Aug 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@findepi Why? Wouldn't this mean that the configuration property is never used?
Or do you mean to say to change the default value to be Integer.MAX_VALUE instead of 10k?

I want to confirm since I've asked @posulliv to change this to use the default value here (instead of MAX_VALUE).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is per-transaction cache, and transaction = query in JDBC connectors. Hence, for example, 1d hard-coded eviction time, which is "infinity in practice".
Is there any problem with not capping per-transaction cache with cacheMaximumSize?

The cacheMaximumSize will still be applied in @Inject CachingJdbcClient::new, which is used to configure permanent CachingJdbcClient (singleton).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@findepi Thanks for pointing out this is per-transaction which I missed.
I think it should be fine to make per-transaction cache unbounded. It would help queries to see consistent metadata during runtime.

@posulliv Can you revert my suggestion and use Integer.MAX_VALUE here.

});

// cleanup
this.jdbcClient.dropTable(SESSION, first);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

redundant this. ?

@ConfigDescription("Maximum number of objects stored in the metadata cache")
public BaseJdbcConfig setCacheMaximumSize(long cacheMaximumSize)
{
this.cacheMaximumSize = cacheMaximumSize;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to reject configuration like

metadata.cache-maximum-size = 100
# metadata.cache-ttl is not set

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is a good idea. As an admin, it would be nice to know that changing the cache size does not enable the cache unless cache-til is set.

I added a validation method that validates the cache config to do this.

@posulliv posulliv force-pushed the jdbc-caching-client-updates branch 4 times, most recently from 79e4e02 to 171e39c Compare July 26, 2021 15:55
@posulliv
Copy link
Contributor Author

@findepi thanks for having a look. Updated based on your feedback.

Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments.

What is the motivation for the change? Is it that the cache was unbounded previously and grew very large at times?

@posulliv
Copy link
Contributor Author

posulliv commented Aug 2, 2021

What is the motivation for the change? Is it that the cache was unbounded previously and grew very large at times?

@hashhar there are a few motivations for the changes:

  • the cache can grow unbounded and like you mentioned, it can grow large for a RDBMS with many objects in it being queried through Trino. It's not that it grows to be massive in terms of memory usage but we would like to guarantee it can never grow beyond a configured limit. Particularly on some clusters we manage that have many RDBMS catalogs with metadata caching enabled.
  • when thinking about heap memory sizing for the coordinator, it's nice to have a rough idea of how much memory each cache will require when it is completely full.
  • we have no insights into how utilized the metadata cache is at the moment so we wanted to add some JMX metrics to get an idea of request/hit/miss rates.

@posulliv posulliv force-pushed the jdbc-caching-client-updates branch 2 times, most recently from b1553aa to 11a9a01 Compare August 2, 2021 18:31
@posulliv
Copy link
Contributor Author

posulliv commented Aug 2, 2021

@hashhar @wendigo thanks for your comments! Updated based on your feedback.

@@ -45,7 +46,7 @@ public JdbcMetadata create(JdbcTransactionHandle transaction)
jdbcClient,
Set.of(),
new SingletonIdentityCacheMapping(),
new Duration(1, DAYS), true),
new Duration(1, DAYS), true, DEFAULT_METADATA_CACHE_SIZE),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

put true, DEFAULT_METADATA_CACHE_SIZE on separate lines

@posulliv posulliv force-pushed the jdbc-caching-client-updates branch 2 times, most recently from 969a7db to 69f9006 Compare August 3, 2021 14:07
Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM % comment.

{
if (metadataCacheTtl.equals(CACHING_DISABLED) && cacheMaximumSize != BaseJdbcConfig.DEFAULT_METADATA_CACHE_SIZE) {
throw new IllegalArgumentException(
format("Invalid JDBC metadata caching configuration. No TTL is configured (%s) so metadata caching is disabled and changing the cache size to %s has no effect",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
format("Invalid JDBC metadata caching configuration. No TTL is configured (%s) so metadata caching is disabled and changing the cache size to %s has no effect",
format("metadata.cache-ttl must be set to a non-zero value when metadata.cache-maximum-size is set",

Maybe this? With an exception the actual property names causing issue should be present IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I like your suggestion as it is more concise. I went through a few iterations of this error message. Its hard to come up with a good error message :)

@posulliv posulliv force-pushed the jdbc-caching-client-updates branch from 69f9006 to 8ec4c85 Compare August 3, 2021 14:18
Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@hashhar hashhar merged commit 3cfa652 into trinodb:master Aug 9, 2021
@hashhar hashhar added this to the 361 milestone Aug 9, 2021
@hashhar hashhar mentioned this pull request Aug 10, 2021
10 tasks
@posulliv posulliv deleted the jdbc-caching-client-updates branch February 9, 2022 01:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants